Re: Low Budget Performance, Part 2 - Mailing list pgsql-performance

From eric soroos
Subject Re: Low Budget Performance, Part 2
Date
Msg-id 30995191.1173642930@[4.42.179.151]
Whole thread Raw
In response to Re: Low Budget Performance, Part 2  (Ron Johnson <ron.l.johnson@cox.net>)
Responses Re: Low Budget Performance, Part 2  ("scott.marlowe" <scott.marlowe@ihs.com>)
List pgsql-performance
> >
> > For 1-10 clients, IDE gets 25-30 tps, SCSI 40-50  (more with more clients,
> > roughly linear).
> >
> > The CPU was hardly working in these runs (~50% on scsi, ~20% on ide), vs nearly
> > 100% on the previous run.
>
> Going back to the OP, you think the CPU load is so high when using SCSI
> because of underperforming APPLE drivers?

I think it's a combination of one significant digit for cpu load and more transactions on the scsi system. I'm
concludingthat since the processor wasn't redlined, the bottleneck is somewhere else. Given the heavily transactional
natureof these tests, it's reasonable to assume that the bottleneck is the disk.  

10 tps= 600 transactions per minute, so for the scsi drive, I'm seeing 3k transactions / 10k revolutions, for a 30%
'saturation'. For the ide, I'm seeing 1800/7200 = 25% 'saturation'.  

The rotational speed difference is 40% (10k/7.2k), and the TPS difference is about 60% (50/30 or 40/25)

So, my analysis here is that 2/3 of the difference in transaction speed can be attributed to rotational speed. It
appearsthat the scsi architecture is also somewhat more efficient as well, allowing for a further 20% increase (over
baseline)in tps. 

A test with a 7.2k rpm scsi drive would be instructive, as it would remove the rotational difference from the equation.
Asthe budget for this is $0, donations will be accepted. 

eric




pgsql-performance by date:

Previous
From: eric soroos
Date:
Subject: Re: Low Budget Performance, Part 2
Next
From: eric soroos
Date:
Subject: Re: Low Budget Performance, Part 2